Generated code - Databinding, SelfServicing

Preface

Databinding is a .NET feature which can drastically increase productivity. It is also a technique that works both with single objects and properties as well with collections with objects. To be able to use databinding with the generated code, both the entity objects and the entity collections are made databinding aware. This section describes the databinding functionality available through the generated code for Windows Forms, WPF and 1-way ASP.NET databinding.

Implemented functionality

This section briefly discusses the implemented functionality in the various classes of the generated code you will use with databinding.

Entity classes
All entity classes implement the following databinding aware interfaces:

• INotifyPropertyChanged.
• IEditableObject
• IDataErrorInfo

Typed views and typed lists
Typed View and Typed List objects are generated as classes deriving from DataTable, and because the DataTable already is equipped with all the databinding functionality necessary, you can bind a Typed View or Typed List without trouble to a datagrid or to a set of GUI controls.

Entity collections
Entity collections implement the IListSource interface. This means that bound controls will request from the entity collection  object a separate object they can bind to. An entity collection class instance returns its DefaultView for this. This means that when you set a control's DataSource property to an entity collection instance, the collection won't bind directly to the control though it will bind to the control through an EntityView<T> instance, the object returned by the collection's DefaultView.

This also means that if you create your own EntityView<T> instance on a given entity collection, you can bind that EntityView<T> to the control instead, to have a subset of the data in an entity collection visible in the control. This is similar to how DataTable and DataView work hand in hand. All actions taken on the data, including e.g. creating new entities in a grid, are performed on the entity collection related to the bound EntityView<T>. For more details, please see: Generated code - using the EntityView class for details.

EntityView<T> implements all useful properties and methods of IBindingList. Among these features are: sorting in grids, making the EntityView<T> read-only, do not allow addition, removal of rows. It furthermore implements ITypedList to make sure only the useful fields/properties of the entity types are visible in the bound control.

Design time support in VisualStudio.NET

To setup databinding at design time, it's recommended you use the Data sources feature in Visual Studio.NET. Create a Data Source based on an entity type in the generated code, e.g. CustomerEntity. Setup databinding using that data source, e.g. through dragging a BindingSource onto your form. When you set the DataSource property of that BindingSource to the Data Source you created of the entity type, you can design the control bound to the BindingSource. At runtime, set the DataSource property of the BindingSource instance to a fetched EntityCollection<T> instance. This will make sure the data shows up in the control bound to the BindingSource. 

For ASP.NET webforms and 2-way databinding and how to setup this databinding using DataSourceControls, please see:  Generated code - Databinding with ASP.NET 2.0

Databinding and inheritance

When using an inheritance hierarchy, you typically have subtypes with more fields than the supertypes. As LLBLGen Pro supports polymorphic fetches, it can be in an entity collection, entities of various types (all from the same inheritance hierarchy) are found. If several of these entity types have fields not found in their supertypes or siblings in the hierarchy, what will show up in a grid if such a collection is bound to that grid?

LLBLGen Pro will provide to the bound control properties for all fields which are found in the type set for the collection. For example, if you've a hierarchy like Employee <- Manager <- BoardMember, and you fetch all Manager entities into a ManagerCollection, it can be that one or more of the Manager entities in the collection are actually of type BoardMember, due to Polymorphic Fetching. BoardMember entities have for example a field called CompanyCarId, and Manager entities don't have that field. Binding the fetched ManagerCollection to a grid, only the fields from the Manager entity will show up in the grid, as that's the type set for the collection bound, ManagerCollection.